Data Request Restrictions Model

This document provides a detailed explanation of the restrictions model used within the ProofRequestCredential class. The restrictions model defines the constraints for credentials, ensuring that only the intended schemas, issuers, and attributes are used.

---

Structure of the restrictions Field

Restrictions - it's constraints to find or filter credential in user wallet to ensure you get data from right credential.

Example

{
  "credentials": [
    {
      "format": "w3c",
      "name": "W3C Verified Email",
      "restrictions": {
        "schemaId": "https://137.dev-one37.id/bc/public/schemas/com.one37id.email/1.0",
        "attributes": [
          {
            "key": "_namespace",
            "value": "personal.contact.verifiedemail"
          }
        ]
      }
    }
  ]
}

Explanation of Fields

1. schemaId

   • Type: string (Optional)
   • Description: Specifies the unique identifier for the schema that the credential must adhere to. This ensures that only credentials matching the specified schema are valid.
   • Example: "https://137.dev-one37.id/bc/public/schemas/com.one37id.email/1.0"

2. issuerDid

   • Type: string (Optional)
   • Description: Defines the Decentralized Identifier (DID) of the issuer. This restricts the credential to those issued by a specific entity.
   • Example: "did:example:123456789abcdefghi"

3. attributes

   • Type: AttributeModel[] (Optional)
   • Description: Specifies attribute-level constraints, such as key-value pairs that the credential must include.
   • Structure:
     • key: The name of the attribute (e.g., "_namespace").
     • value: The expected value for the attribute (e.g., "personal.contact.verifiedemail").
   • Example:

     [
       {
         "key": "_namespace",
         "value": "personal.contact.verifiedemail"
       }
     ]

---

Best Practices

1. Define Specific Constraints

   • Restrict issuers with issuerDid for added security.

2. Validate Attributes

   • Use attribute-level restrictions to ensure the credential contains required key-value pairs.

3. Optional but Recommended

   • While restrictions is optional, its inclusion enhances security and precision in credential verification.

---

By leveraging the restrictions model effectively, you can create robust and secure credential workflows.